Is this based on manual code inspection or did you encounter a problem where tf_flag was actually read before it was initialized?

I ask this because immediately before line 2016 we have a NULL check on the c_prev variable which is always false the first time through the loop. On subsequent loop iterations tf_flag is guaranteed to be initialized due to the switch statement starting on line 2025.

However, if you've run into a problem where tf_flag is actually being read before it is initialized please let use know and we can work to fix it.

Is this based on manual code inspection or did you encounter a problem where tf_flag was actually read before it was initialized?

I ask this because immediately before line 2016 we have a NULL check on the c_prev variable which is always false the first time through the loop. On subsequent loop iterations tf_flag is guaranteed to be initialized due to the switch statement starting on line 2025.

However, if you've run into a problem where tf_flag is actually being read before it is initialized please let use know and we can work to fix it.

Yes, it's based on manual code inspection :)

Yes, it's based on manual code inspection :)

Thanks for the clarification. I appreciate the time you spent looking at the code, but I don't believe this is an actual bug as described above, and thus I don't believe this PR is needed.

I'll leave this PR open for a bit in case anyone wants to comment on this further, but as of right now I believe we can close this PR without merging.

Yes, it's based on manual code inspection :)

Thanks for the clarification. I appreciate the time you spent looking at the code, but I don't believe this is an actual bug as described above, and thus I don't believe this PR is needed.

I'll leave this PR open for a bit in case anyone wants to comment on this further, but as of right now I believe we can close this PR without merging.

No problem